Based on #110, I think we do need to support allocating N minors without actually registering devices on them. I think the best way to do that is a second builder method minor_count. It can be an Option<u16> on the Builder and default to len() if it's not provided.

I don't totally understand what binderfs is doing with chrdevs. It looks it's calling alloc_chrdev_region and never calling cdev_add? and that's okay because it opening binderfs chrdevs doesn't actually go through chrdev_open because binderfs is its own filesystem? And it instead... just populates dentries or something?

I don't think that "allocate N chrdevs with operations, and M more without" is quite right, because

• I don't think you'd want to do both (even binderfs, which has one static device named binder-control, puts together that device's inode manually).
• File operations isn't really the right abstraction here, those devices do in fact have file operations (binder_ctl_ops, and binder_ops defined in the core binder code).

Two possible ideas for what to do with the API:

1. Have a second builder method saying "Instead of initializing chrdevs, allocate N minors but do not initialize them." Throw a runtime error if you call both .reserve() and .register_device() on the same builder. (Or a compile-time type error, if you really want.)
2. Split up registration and creation into two steps (which mirrors the underlying kernel API more closely, anyway) into a Registration object and a CharacterDevices object that takes ownership of the Registration. Then binderfs can just skip the second step.

But I'm not totally sure I understand what a good API looks like, here.